\section{Case Study}
\label{sec:casestudy}

In this section, we report our case study for constructing an infrastructure to support runtime management of JOnAS systems based on C2-styled architecture model. We choose JOnAS as a target platform because JOnAS is a widely used open source J2EE application server, achieving the scale of systems in actual use. Moreover, we can use a well know application, JPS, to evaluate the effect of the generated infrastructure, and use the build-in JOnAS admin tool as a reference. We choose C2 styled architectural model in this case study because C2 is a well-researched architecture style and its advantages on managing GUI systems are widely accepted. 

We have briefly revealed the effect this constructed infrastructure in Section~\ref{sec:overview.example}, and in this section, we will focus on how we construct this infrastructure based on our framework, demonstrating that our framework can improve this constructing process to be productive. 

\subsection{Constructing the runtime architecture infrastructure}

Our framework is implemented as several Eclipse plug-ins, depending on a number of reusable plug-ins or libraries like EMF, medini QVT, Beanbag, etc. The whole constructing process is performed under Eclipse environment, as shown in Figure~\ref{fig:process}. 


\begin{figure}
	\centering
		\includegraphics[width=0.90\textwidth]{process}
	\caption{Process for constructing an infrastructure under our framework}
	\label{fig:process}
\end{figure}

First, we use a graphical Ecore editor to construct an Ecore meta-model. The architecture meta-model is shown in the left part of Figure~\ref{fig:metamodels}. According to C2 style, this meta-model currently includes three classes, i.e. \texttt{Component}, \texttt{Connector} and \texttt{Architecture}. \texttt{Components} have some attributes, may link to connectors through ``above'' or ``below'' references, and may contain some inner architecture. From this meta-model, we generate three plug-in projects under the help of EMF.

Second, we construct another Ecore meta-model to specify the kind of system states as show in the right part of Figure~\ref{fig:metamodels}. This meta-model contains classes like \texttt{EntityBean}, \texttt{WebModule}, \texttt{DataSource}, etc. according to the types of MBeans provided by JOnAS JMX with same names. We add some attributes into these classes according to the attributes of corresponding MBean types. The inheritance structure between these classes agrees with the class hierarchy defined between the MBean classes. \texttt{MBeanServer} is a special class defining the JOnAS server itself. We also add annotations to these meta-model elements with the JMX specific code for accessing JOnAS server. An example of these annotations can be found in Table~\ref{tab:metasample}. We also use EMF to generate three projects. 

\begin{figure}
	\centering
		\includegraphics[width=1.00\textwidth]{metamodels}
	\caption{Meta-models for architecture and system}
	\label{fig:metamodels}
\end{figure}

Third and last, we define a QVT transformation to specify the consistency relation we expect between architectural models and system states. In Table~\ref{tab:samplerelation}, we list 2 of the 6 relations we defined. 

\begin{table}\scriptsize
	\label{tab:workload}
	\caption{Manual, generated and framework artifacts}
	\centering
		\begin{tabular}{|c|l|r|rl|} 
			\hline
			 & item & artifact & \multicolumn{2}{|c|}{quantified workload} \\ \hline
			\multirow{4}*{\begin{sideways}Manual\end{sideways}} 
			 & define~C2 & Ecore~model & 29 & model~elements \\ 
			 & define~JOnAS & Ecore~model & 61 & model~elements \\
			 & add annotation & Java~code & 474 & LOC \\ 
			 & define~relation & QVT~text & 207 & LOC \\			  
			\hline
			\hline
			\multirow{2}*{\begin{sideways}Gen.\end{sideways}}	
			 & for arc & Java~code & 8761 & LOC \\
			 & for sys & Java~code & 18263 & LOC \\ 
			\hline
			\multirow{2}*{\begin{sideways}Fra.\end{sideways}}
			 & common meta-model & Ecore~model & 17 & model~elements \\
			 & Synch.~and~utility & Java~code & 2130 & LOC* \\
			\hline
			\multicolumn{5}{|r|}{*exclude reused libraries and plug-ins} \\ \hline
		\end{tabular}
\end{table}

Table~\ref{tab:workload} lists the quantified manual workload for implementing this case, comparing with the size of generated code and framework. From the simple comparison we can at least conclude that that our framework does save some effort for developers. We have not found a manual-developed runtime architecture infrastructure with same capabilities as a control sample, but we believe that seven hundred lines of code is not a heavy load for a developer familiar with JOnAS JMX, and neither is the one hundred of model elements for a developer familiar with EMF and QVT.

\subsection{Using the constructed infrastructure}

To use the constructed infrastructure, we can export the generated projects into plug-in jar files, and copy them into the ``plugins'' directory of an Eclipse platform. After launching this Eclipse, we can create a empty project, and copy the two meta-models and the QVT file into this project. Now we can import an architecture model or create an empty one, modify it with text editor or a tree-based model editor provided by eclipse, and synchronize it with a running JOnAS system by clicking a tool-bar button. 

In this case study, to intuitively reveal the effect of this infrastructure, we also use Eclipse GMF to generate a graphical editor for the architectural model, as shown in Figure~\ref{fig:productsnapshot}. 
To generate this graphical editor, we created 3 GMF required models with 34 model elements in total, without writing a single line of code. 
Notice that is work is actually outside the scope of our framework, since it is only in charge of maintaining the causal connection.

We have briefly shown the effect of using this infrastructure in Section~\ref{sec:overview}, through some basic scenarios for runtime management of the JPS application.

We did an experiment on the infrastructure constructed in this case study, on a laptop computer with an Intel Pentium M 1.6GHz process, and 1.5G memory. The Eclipse 3.4 platform, which is the host of architecture editor and our infrastructure, and a JOnAS 4.9.7 application server are all running on this same computer. The architectural model contains 69 components and connectors, while the JOnAS server contains over 300 manageable elements (MBeans), and 47 elements among them, along with over 100 attributes will be reflected to the architecture model. The experiment result is listed in Table~\ref{tab:timespent}. 

\begin{table}\scriptsize
	\caption{Synchronization time spent}
	\label{tab:timespent}
	\centering
		\begin{tabular}{|c|c|r|}\hline
		No. & modifications on arch. model & sync. time spend \\ \hline
		1 & - & 5137 ms \\
		2 & - & 3012 ms \\
		3 & change 1 attribute value & 2917 ms \\
		4 & change 10 attribute value & 3105 ms  \\
		5 & add 1 WebModule & 3262 ms \\
		5 & remove 1 WebModule and add 2 EJB & 3327 ms \\
		6 & relink between WebModule and EJB & 3329 ms \\
		\hline			
		\end{tabular}
\end{table}

The number in the first column represents the order for executing ``synchronization''. The first synchronization took quite a long time, and we doubt it is because the JVM has to load many classes from the relevant plug-ins and libraries. The 6th synchronization took the second long time because in our current wrapping, to change a EJB reference, we have to reload the EJB or the Web Module. 

\subsection{Discussion on some other concerns}

\paragraph{Performance}
As an initial attempt, we did not pay too much attention on the performance of constructed infrastructures, although performance is also an important concerns. The experiment above shows that although this infrastructure's performance is not good, but it is still acceptable. Several seconds of time spent are reasonable for manual management. We have tried to use the build-in JOnAS Admin web page to deploy a WebModule, and after clicking the ``confirm'' button, we also have to wait for more than a second until the whole page is refreshed.  

Actually, there are many potential ways to improve the performance, like caching the retrieved system state, employing incremental transformation \cite{Giese06}, etc. and these improvement may be important for the infrastructures to support automated management agents, like self-adaptation engine. We will emphasize on the performance in our further work.

\paragraph{Maintainability and incremental development}
We are not very familiar with JOnAS JMX interface, and thus we made some mistakes when filling the hook method. So, the first version of the constructed infrastructure also have some defects, like receiving exception when reading some attribute. Since the specific code are directly mapped to elements, attributes or references, we can easily locate the mistakes from a few lines of code in annotations. We think this is a reflection of the maintainability of infrastructures constructed under our framework. We also tried to reflect extra kinds of manageable elements into architectural models, and the experiment confirm that we just need to \emph{supplement} the meta-models, QVT transformation, without breaking the existing effort. So we can also say that our framework is good for incremental development.


 



 





